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SPECIFICATION 

[Electronic Version 1.0] 



METHOD AND SYSTEM OF 
REMOTE DIAGNOSTIC, CONTROL 
AND INFORMATION 
COLLECTION USING A DYNAMIC 
LINKED LIBRARY OF MULTIPLE 
FORMATS AND MULTIPLE 
PROTOCOLS WITH RESTRICTION 
ON PROTOCOL 

Abstract of the Disclosure 

A method, system and computer program product for (1) collecting information from 
a remote application unit and/or (2) diagnosing or controlling the remote application unit. 
By utilizing a shareable computer code device (e.g., a dynamic linked library), a new 
application can utilize tested, proven code without having to reproduce existing 
functionality. Moreover, by supporting multiple data formats and/or multiple 
communication protocols, a computer code device increases the likelihood that a supported 
format and/or protocol will be either receivable or understandable by a receiver. 
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METHOD AND SYSTEM OF 
REMOTE DIAGNOSTIC, CONTROL 
AND INFORMATION 
COLLECTION USING A DYNAMIC 
LINKED LIBRARY OF MULTIPLE 
FORMATS AND MULTIPLE 
PROTOCOLS WITH RESTRICTION 
ON PROTOCOL 

Cross-Reference to Related Applications 

Referenced-applications 

The present application, attorney docket number 5244-0125-2, is related to the following 
U.S. applications and patents: application 09/440,692 of 1999-1 1-16 ; application 
09/440,647 of 1999-1 1-16 ; application 09/440,646 of 1999-1 1-16 ; application 
09/440,693 of 1999-1 1-16 ; application 09/440,645 of 1999-1 1-16 ; application 
09/408,443 of 1999-09-29 ; application 09/407,769 of 1999-09-29 ; application 
09/393,677 of 1999-09-10 ; application 09/31 1,148 of 1999-05-13 ; application 
09/192,583 of 1998-1 1-17 ; application 09/190,460 of 1998-1 1-13 ; application 
08/883,492 of 1997-06-26 ; application 09/108,705 of 1998-07-01 ; application 
09/107,989 of 1998-07-01 ; application 08/997,482 of 1997-12-23 ; application 
08/997,705 of 1997-12-23 ; application 08/738,659 of 1996-10-30 ; application 
08/738,461 of 1996-10-30 ; application 09/457,669 of 1999-12-09 ; application 
08/916,009 of 1997-08-21 ; application 07/902,462 of 1992-06-19 ; application 
07/549,278 of 1990-07-06 ; 
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. This application is also related to the following co-pending applications: Attorney 
Docket No. 5244-0121-2; 5244-0122-2 and 5244-0126, all of which are filed on even date 
herewith. The contents of each of those applications and patents is incorporated herein by 
reference. 

Statement Regarding Federally Sponsored Research 

Not Applicable 

Reference to a Microfiche Appendix 

Not Applicable 

Background of the Invention 
Description of Related Art 

[pi] With the rise of microprocessor-based appliances and devices, software development 
has clearly become a significant business. In evaluating and supporting the appliances and 
devices, it may be beneficial to monitor exactly how events in the appliance and device 
occur and how the states are changing. An example of events is an action caused by user 
interaction with an appliance. It may be helpful for a software developer to know which 
commands a user uses most often and how long those commands take to execute. Such an 
analysis is often referred to as "profiling." (Analogous analysis was performed on 
instructions in instruction sets to develop reduced instruction set computing (RISC) 
instructions.) 

[p2] Further, in designing devices with which a human interacts, it may be desirable to 
monitor how the user interacts with such a device. As an example, it may be desirable to 
monitor how a user utilizes a control panel of an image forming device such as a 
photocopier, facsimile machine, printer, scanner, an appliance such as a microwave oven, 
VCR, digital camera, cellular phone, palm top computer, etc. 
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[p3] Further, it may be desirable to monitor the state of the appliances and devices to 
provide diagnostics, services and maintenances. Some events may be caused by the 
internal changes within the appliances and devices. Some events may be caused by 
abnormal conditions such as paper jam in the copiers. Some error conditions and warning 
conditions may be caused by errors in the software installed in the target appliances and 
devices. 

[p4] Further, users are increasingly utilizing the Internet. There is significant interest in 
how users use the Internet, particularly with respect to how users may use certain web 
pages. Monitoring a user's usage of the Internet may also become significant. 

[p5] It may also be desirable to determine how a user is utilizing a certain application unit 
(e.g., a computer running a software application, a device with an interface to be operated 
by a user, or a web page). The user's usage of the application unit must be monitored and 
effectively communicated to a remote party. 

Field of the Invention 

[p6] This invention generally relates to a method and system that can monitor and 

communicate events at plural target applications of an application unit by using at least one 
Dynamic Linked Library (DLL) shared among the plural target applications. DLL supports 
multiple data formats and multiple protocols to communicated the event data. The 
application unit can specify at least one protocol to be used to report the information in at 
least one format from the application unit. Each of the at least one protocol and each of the 
at least one format can be defined through the interface function. 

Brief Summary of the Invention 

[p7] One object of the present invention is to provide a novel and effective system for 
monitoring events of a target application of an application unit. 
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[p8] A further object of the present invention is to provide a system for communicating 
data obtained by monitoring events of a target application of an application unit to a 
remote party. 

[p9] A further object of the present invention is to provide a system for communicating 
data obtained by monitoring events of a target application of an application unit to a 
remote party allowing various data formats and communication protocols to facilitate the 
communication system configuration and received data analysis. 

[plO] A further object of the present invention is to provide a system for communicating 
data obtained by monitoring events of a target application of an application unit to a 
remote party allowing various data formats that ease the analyses of received data at the 
receiving side. 

[pi 1] A further object of the present invention is to efficiently communicate the monitored 
event information to a transmission unit. 

[pi 2] A further object of the present invention is to efficiently verify the combination of 
the two parameters specifying the format and protocol and to meet the restriction 
requirement on the second parameter. 

[pi 3] The present invention achieves these and other objects by monitoring the events of a 
target application of an application unit. Monitoring examples include (1) monitoring a 
software program being executed on a computer or workstation under control of a user, 
(2) monitoring usage of a control panel of an image forming apparatus (e.g., a copying 
machine, printer, facsimile, or scanner), an appliance (e.g., a microwave oven, VCR, 
digital camera, cellular phone, or palm top computer), (3) monitoring any internal state 
changes such as error conditions and warning conditions within appliances, devices and 
any systems and sending the results when requested or when events occur or when preset 



Page 5 of 79 



time interval occurs, (4) externally monitoring states of appliances, devices or system by 
polling at regular interval, and (5) generally monitoring any other device or service. The 
data obtained by monitoring events of a target application of an application unit, 
appliance, or device can, as a further feature in the present invention, be collected, logged 
and communicated to a desired location by a store-and-forward protocol (e.g., Internet e- 
mail) or a "direct" connection protocol in which a socket connection is made to an 
ultimate destination machine (e.g., using FTP or HTTP). The use of store-and-forward 
communication reduces the costs associated with communicating such data. The data can 
be communicated to the desired location at several instances. Such instances include each 
time a user exits a target application, or after a predetermined number of times that a user 
has utilized and exited the target application of the application unit. If the configuration 
allows and if necessary, the direct connection between the monitored application and the 
monitoring system can be established in addition to the store-and-forward 
communication. 

Brief Description of the Several Views of the Drawings 

[pi 4] A more complete appreciation of the present invention and many of the attendant 
advantages thereof will be readily obtained as the same becomes better understood by 
reference to the following detailed description when considered in connection with the 
accompanying drawings, wherein: 

[pi 5] Figure 1 illustrates three networked business office machines connected to a network 
of computers and databases through the Internet; 

[pi 6] Figure 2 illustrates the components of a digital image forming apparatus; 

[pi 7] Figure 3 illustrates the electronic components of the digital image forming apparatus 
illustrated in Figure 2; 
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[pi 8] Figure 4 illustrates details of the multi-port communication interface illustrated in 
Figure 3; 

[pi 9] Figure 5 illustrates an alternative system configuration in which business office 

devices are either connected directly to the network or connected to a computer which is 
connected to the network; 

[p20] Figure 6A illustrates in block diagram format the flow of information to and from an 
application unit using electronic mail; 

[p21] Figure 6B illustrates an alternative way of communicating using electronic mail in 
which the computer which is connected to the application unit also serves as a message 
transfer agent; 

[p22] Figure 6C illustrates an alternative way of communicating using electronic mail in 
which an application unit includes a message transfer agent for exchanging electronic 
mail; 

[p23] Figure 6D illustrates an alternative way of communicating using electronic mail in 
which a mail server acts as POP 3 server to receive mail for an Appliance/Device and as 
an SMTP server to send mail for Appliance/Device; 

[p24] Figure 7 illustrates an alternative manner of sending messages across the Internet; 

[p25] Figure 8 illustrates an exemplary computer which may be connected to the device 
and used to communicate electronic mail messages; 

[p26] Figure 9 is a block diagram illustrating connections between a monitoring and 
logging subsystem, a communications subsystem and a target application of an 
application unit in the present invention; 
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[p27] Figure 10 shows a first example of an application unit to which the present invention 
can be applied; 

[p28] Figure 1 1 shows a second example of an application unit to which the present 
invention can be applied; 

[p29] Figure 12A shows the general architecture of the system; 

[p30] Figure 12B is an exemplary EventData class interface for use in the architecture of 
Figure 12 A; 

[p3 1] Figure 12C is an exemplary FormattedEventData class interface for use in the 
architecture of Figure 12 A; 

[p32] Figure 13 shows the calling sequence of the interface functions from application 
software within application unit, appliance or device; 

[p33] Figure 14 shows the processing when the Application software instructs DLL to stop 
monitoring and send the monitored information with the specified format(s) using the 
specified protocol(s); 

[p34] Figure 1 5 shows the data structure used for intelligent formatting; 

[p35] Figure 16A and 16B shows the source code that implements the processing shown in 
Figure 14; 

[p36] Figure 17 shows the data structure to handle the intelligent protocol processing with 
caching of the processing function; 

[p37] Figures 1 8 A through 1 8D show a Processor Builder class according to one 
embodiment of the present invention; 
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[p38] Figure 19 shows the processing when the Application software instructs the system 
to use the specified format and protocol to transmit the monitored data; 

[p39] Figure 20 shows the class structure to keep track of the combination of format and 
protocols; 

[p40] Figure 21 shows the processing of two parameters passed by the Application 
software through the System Manager computer code device; 

[p41] Figures 22 shows the processing to get a format parameters and associated list of 
protocols after checking the restriction on the protocol; 

[p42] Figures 23A and 23B are class specification of CFormatProtocol_InformationBase 
class that interface with the System Manager computer code device; 

[p43] Figures 24A and 24B are class specification of CFormatProtocolCombinationCheck 
class to verify the combination of format and protocol; and 

[p44] Figures 25A, 25B and 25C are class specification of CProtocolRestrictionCheck 
class where the steps in the oneFormatRestriction function shows the process to modify 
the map structure. 

Detailed Description of the Invention 

[p45] Referring now to the drawings, wherein like reference numerals designate identical 
or corresponding parts throughout the several views, Figure 1 illustrates (1) various 
machines and (2) computers for monitoring, diagnosing and controlling the operation of 
the machines. In Figure 1, there is a first network 16, such as a Local Area Network 
(LAN) connected to computer workstations 17, 18, 20 and 22. The workstations can be 
any type of computers including IBM Personal Computer compatible devices, Unix- 
based computers, or Apple Macintoshes. Also connected to the network 16 are (1) a 
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digital image forming apparatus 24, (2) a facsimile machine 28, and (3) a printer 32. As 
would be appreciated by one of ordinary skill in the art, two or more of the components 
of the digital image forming apparatus 24 and the facsimile machine 28 can be combined 
into a unified "image forming apparatus." The devices 24, 28 and 32 and the workstations 
17, 18, 20 and 22 are referred to as machines or monitored devices and other types of 
devices may be used as the machines or monitored devices, including any of the devices 
discussed below. In some configurations, one or more workstations may be converted to 
business office appliance. One example of such appliance is eCabinet from Ricoh 
demonstrated at Fall Comdex in 1999 at Las Vegas. Also, a facsimile server (not 
illustrated) may be connected to the network 16 and have a telephone, ISDN (Integrated 
Services Digital Network), cable or wireless connection. In addition to the digital image 
forming apparatus 24, facsimile machine 28, and printer 32 being connected to the 
network 16, these devices may also include conventional telephone and/or ISDN and/or 
cable and/or wireless connections 26, 30 and 34, respectively. As is explained below, the 
business office machines, business devices or business office appliances 24, 28 and 32 
communicate with a remote monitoring, diagnosis and control station, also referred to as 
a monitoring device, through the Internet via the network 16 or by a direct telephone, 
ISDN, wireless, or cable connection. 

[p46] In Figure 1, a wide area network (WAN) (e.g., the Internet or its successor) is 

generally designated by 10. The WAN 10 can either be a private WAN, a public WAN or 
a hybrid. The WAN 10 includes a plurality of interconnected computers and routers 
designated by 12A-12L The manner of communicating over a WAN is known through a 
series of RFC documents obtained by HTTP//:www.ietf.org/rfc.html, including RFC 821 
entitled "Simple Mail Transfer Protocol"; RFC 822 entitled "Standard for the Format of 
ARPA Internet Text Message"; RFC 959 entitled "File Transfer Protocol (FTP)"; RFC 
2045 entitled "Multipurpose Internet Mail Extensions (MIME) Part One: Format of 
Internet Message Bodies"; RFC 1894 entitled "An Extensible Message Format for 
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Delivery Status Notifications"; RFC 1939 entitled 'Tost Office protocol - Version 3"; 
and RFC 2298 entitled "An Extensible Message Format for Message Disposition 
Notifications/' The contents of each of those references are incorporated herein by 
reference. 

[p47] TCP/IP related communication is described, for example, in the book "TCP/IP 
Illustrated," Vol. 1, The Protocols, by W.R. Stevens, from Addison- Wesley Publishing 
Company, 1994, which is incorporated herein by reference. Volumes 1-3 of 
"Internetworking with TCP/IP" by Comer and Stevens are also incorporated herein by 
reference in their entirety. 

[p48] In Figure 1, a firewall 50A is connected between the WAN 10 and the network 16. A 
firewall is a device that allows only authorized computers on one side of the firewall to 
access a network, computers or individual parts on the other side of the firewall. Firewalls 
are known and commercially available devices and/or software (e.g., SunScreen from Sun 
Microsystems Inc.). Similarly, firewalls SOB and 50C separate the WAN 10 from a 
network 52 and a workstation 42, respectively. Additional details on firewalls can be 
found in "Firewalls and Internet Security" by W. R. Cheswick, and S. M. Bellovin, 1994, 
Addison- Wesley Publishing, and "Building Internet Firewalls" by D. B. Chapman and E. 
D. Zwicky, 1995, O'Reilly & Associates, Inc. The contents of those references are 
incorporated herein by reference. 

[p49] The network 52 is a conventional network and includes a plurality of workstations 
56, 62, 68 and 74. These workstations may be in different departments (e.g., marketing, 
manufacturing, design engineering and customer service departments) within a single 
company. In addition to the workstations connected via the network 52, there is a 
workstation 42, which is not directly connected to the network 52. Information in a 
database stored in a disk 46 may be shared using proper encryption and protocols over the 
WAN 10 to the workstations connected directly to the network 52. Also, the workstation 



Page 11 of 79 



42 includes a direct connection to a telephone line and/or ISDN and/or cable and/or 
wireless network 44 and the database in disk 46 may be accessed through the telephone 
line, ISDN, cable or wirelessly. The cable used by this invention may be implemented 
using a cable which typically is used to carry television programming, a cable which 
provides for high speed communication of digital data typically used with computers or 
the like, or any other desired type of cable. 

[p50] Information of the business office machines, business devices or business office 

appliances 24, 28 and 32 may be stored in one or more of the databases stored in the disks 
46, 54, 58, 64, 70 and 76. Known databases include (1) SQL databases by Microsoft, 
Oracle and Sybase (2) other relational databases, and (3) non-relational databases 
(including object oriented databases). Each of the customer service, marketing, 
manufacturing, and engineering departments may have their own database or may share 
one or more databases. Each of the disks used to store databases is a non-volatile memory 
such as a hard disk or optical disk. Alternatively, the databases may be stored in any 
storage device including solid state and/or semiconductor memory devices. As an 
example, disk 64 contains the marketing database, disk 58 contains the manufacturing 
database, disk 70 contains the engineering database and disk 76 contains the customer 
service database. Alternatively, the disks 54 and 46 store one or more of the databases. 

[p51] In addition to the workstations 56, 62, 68, 74 and 42 being connected to the WAN, 
these workstations may also include a connection to a telephone line, ISDN, cable, or 
wireless network which provides a secure connection to the machine being monitored, 
diagnosed and/or controlled and is used during communication. Additionally, if one 
communication medium is not operating properly, one of the others can be automatically 
used for communication. 
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[p52] A feature of the present invention is the use of a "store-and-forward" mode of 

communication (e.g., Internet e-mail) or transmission between a machine and a compute]' 
for diagnosing and controlling the machine. Alternatively, the message which is 
transmitted may be implemented using a mode of communication that makes direct, end- 
to-end connections (e.g., using a socket connection to the ultimate destination). 

[p53] Figure 2 illustrates the mechanical layout of the digital image forming apparatus 24 
illustrated in Figure 1 . In Figure 2, 101 is a fan for the scanner, 102 is a polygonal mirror 
used with a laser printer, and 103 designates an F lens used to collimate light from a laseir 
(not illustrated). Reference numeral 104 designates a sensor for detecting light from the 
scanner. 105 is a lens for focusing light from the scanner onto the sensor 104, and 106 is a 
quenching lamp used to erase images on the photoconductive drum 132. There is a 
charging corona unit 107 and a developing roller 108. Reference numeral 109 designates 
a lamp used to illustrate a document to be scanned and 110, 111 and 1 12 designate 
mirrors used to reflect light onto the sensor 104. There is a drum mirror 113 used to 
reflect light to the photoconductive drum 132 originating from the polygon mirror 102. 
Reference numeral 114 designates a fan used to cool the charging area of the digital 
image forming apparatus, and 1 1 5 is a first paper feed roller used for feeding paper from 
the first paper cassette 1 17, and 1 16 is a manual feed table. Similarly, 1 1 8 is a second 
paper feed roller for the second cassette 119. Reference numeral 120 designates a relay 
roller, 121 is a registration roller. 122 is an image density sensor and 123 is a 
transfer/separation corona unit. Reference numeral 124 is a cleaning unit, 125 is a 
vacuum fan, 126 illustrates a transport belt, 127 is a pressure roller, and 128 is an exit 
roller. Reference numeral 129 is a hot roller used to fix toner onto the paper, 130 is an 
exhaust fan and 13 1 is the main motor used to drive the digital image forming apparatus. 
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[p54] Figure 3 illustrates a block diagram of the electronic components illustrated in 
Figure 2. The CPU 160 is a microprocessor and acts as the system controller. Random 
access memory (RAM) 1 62 stores dynamically changing information including operating 
parameters of the digital image forming apparatus. A non-volatile memory (e.g., a read 
only memory (ROM) 164 or a Flash Memory) stores (1) the program code used to run the 
digital image forming apparatus and (2) static-state data, describing the copier (e.g., the 
model number, serial number of the copier, and default parameters. 

[p55] There is a multi-port network interface 166 which allows the digital image forming 
apparatus to communicate with external devices through at least one network. Reference 
number 168 represents a telephone, ISDN, or cable line, and numeral 170 represents 
another type of network. Additional details of the multi-port network interface are 
described with respect to Figure 4. An interface controller 172 is used to connect an 
operation panel 174 to a system bus 186. The operation panel 174 includes standard input 
and output devices found on a digital image forming apparatus including a copy button, 
keys to control the operation of the copier such as number of copies, 
reducement/enlargement, darkness/lightness, etc. Additionally, a liquid crystal display 
may be included within the operation panel 1 74 to display parameters and messages of 
the digital image forming apparatus to a user. 

[p56] The local connection interface 171 is a connection through local ports such as 

RS232, the parallel printer port, USB, and IEEE 1394. FireWire (IEEE 1394) is described 
in Wickelgren, L, "The Facts About "FireWire", IEEE Spectrum, April 1997, Vol 34, 
Number 4, pp. 19-25, the contents of which are incorporated herein by reference. 
Preferably, communication utilizes a "reliable" protocol with error detection and 
retransmission. 
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[p57] A storage interface 176 connects storage devices to the system bus 186. The storage: 
devices include a flash memory 178 which can be substituted by a conventional 
EEPROM and a disk 182. The disk 182 includes a hard disk, optical disk, and/or a floppy 
disk drive. There is a connection 180 connected to the storage interface 176 which allows 
for additional memory devices to be connected to the digital image forming apparatus. 
The flash memory 178 is used to store semi-static state data which describes parameters 
of the digital image forming apparatus which infrequently change over the life of the 
copier. Such parameters include the options and configuration of the digital image 
forming apparatus. An option interface 184 allows additional hardware such as an 
external interface to be connected to the digital image forming apparatus. A clock/timer 
187 is utilized to keep track of both the time and date and also to measure elapsed time. 

[p58] On the left side of Figure 3, the various sections making up the digital image 

forming device are illustrated. Reference numeral 202 designates a sorter and contains 
sensors and actuators used to sort the output of the digital image forming device. There is 
a duplexer 200 which allows a duplex operation to be performed by the digital image 
forming device and includes conventional sensors and actuators. The digital image 
forming device includes a large capacity tray unit 198 which allows paper trays holding a 
large number of sheets to be used with the digital image forming device. The large 
capacity tray unit 198 includes conventional sensors and actuators. 

[p59] A paper feed controller 196 is used to control the operation of feeding paper into and 
through the digital image forming device. A scanner 194 is used to scan images into the 
digital image forming device and includes conventional scanning elements such as a 
light, mirror, etc. Additionally, scanner sensors are used such as a home position sensor to 
determine that the scanner is in the home position, and a lamp thermistor is used to ensure 
proper operation of the scanning lamp. There is a printer/imager 192 which prints the 
output of the digital image forming device and includes a conventional laser printing 
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mechanism, a toner sensor, and an image density sensor. The fuser 190 is used to fuse the 
toner onto the page using a high temperature roller and includes an exit sensor, a 
thermistor to assure that the fuser 1 90 is not overheating, and an oil sensor. Additionally, 
there is an optional unit interface 188 used to connect to optional elements of the digital 
image forming device such as an automatic document feeder, a different type of 
sorter/collator, or other elements which can be added to the digital image forming device. 

[p60] Figure 4 illustrates details of the multi-port network interface 166. The digital image 
forming device may communicate to external devices through a Token Ring interface 
220, a cable modem unit 222 which has a high speed connection over cable, a 
conventional telephone interface 224 which connects to a telephone line 168 A, an ISDN 
interface 226 which connects to an ISDN line 168B, wireless interface 228, and a LAN 
interface 230 (e.g., Ethernet) which connects to a LAN 170. Other interfaces (not shown) 
include, but are not limited to, Digital Subscriber Line (DSL) (original DSL, concentric 
DSL, and asymmetric DSL). A single device which connects to both a Local Area 
Network and a telephone line is commercially available from Megahertz and is known as 
the Ethernet-Modem. 

[p61] The CPU or other microprocessor or circuitry executes a monitoring process to 
monitor the state of each of the sensors of the digital image forming device, and a 
sequencing process is used to execute the instructions of the code used to control and 
operate the digital image forming device. Additionally, there is (1) a central system 
control process executed to control the overall operation of the digital image forming 
device and (2) a communication process used to assure reliable communication to 
external devices connected to the digital image forming device. The system control 
process monitors and controls data storage in a static state memory (e.g., the ROM 164 of 
Figure 3), a semi-static memory (e.g., the flash memory 178 or disk 182), or the dynamic 
state memory (e.g., a volatile or non-volatile memory (e.g., the RAM 162 or the flash 
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memory 178 or disk 182)). Additionally, the static state memory may be a device other 
than the ROM 1 64 such as a non-volatile memory including either of the flash memory 
178 or disk 182. 

The above details have been described with respect to a digital image forming device 
but the present invention is equally applicable to other business office machines or 
devices such as an analog copier, a facsimile machine, a scanner, a printer, a facsimile 
server, or other business office machines and business office appliance, or appliances 
(e.g., a microwave oven, VCR, digital camera, cellular phone, palm top computer). 
Additionally, the present invention includes other types of devices which operate using 
store-and-forward or direct connection-based communication. Such devices include 
metering systems (including gas, water, or electricity metering systems), vending 
machines, or any other mechanical device (e.g., automobiles) that need to be monitored 
during operation or remote diagnosis. In addition to monitoring special purpose machines 
and computers, the invention can be used to monitor, control, and diagnose a general 
purpose computer which would be the monitored and/or controlled device. 

Figure 5 illustrates an alternative system diagram of the invention in which different 
devices and subsystems are connected to the WAN 10. However, there is no requirement 
to have each of these devices or subsystems as part of the invention. Each component or 
subsystem illustrated in Figure 5 is individually part of the invention. Further, the 
elements illustrated in Figure 1 may be connected to the WAN 10 which is illustrated in 
Figure 5. In Figure 5, there is illustrated a firewall 50-1 connected to an intranet 260-1. 
The service machine 254 connected to the intranet 260-1 includes therein or has 
connected thereto data 256 which may be stored in a database format. The data 256 
includes history, performance, malfunction, and any other information including 
statistical information of the operation or failure or set-up and components or optional 
equipment of devices which are being monitored. The service machine 254 may be 



Page 17 of 79 



implemented as the device or computer which requests the monitored devices to transmit 
data or which requests that remote control and/or diagnostic tests be performed on the 
monitored devices. The service machine 254 may be implemented as any type of device 
and is preferably implemented using a computerized device such as a general purpose 
computer. 

[p64] Another sub-system of Figure 5 includes a firewall 50-2, an intranet 260-2, and a 
printer 262 connected thereto. In this sub-system, the functions of sending and receiving 
electronic messages by the printer 262 (and similarly by a copier 286) are performed by 
(1) circuitry, (2) a microprocessor, or (3) any other type of hardware contained within or 
mounted to the printer 262 (i.e., without using a separate general purpose computer). 

[p65] An alternate type of sub-system includes the use of an Internet service provider 264 
which may be any type of Internet service provider (ISP), including known commercial 
companies such as America Online, Earthlink, and Niftyserve. In this sub-system, a 
computer 266 is connected to the ISP 264 through a digital or analog modem (e.g., a 
telephone line modem, a cable modem, modems which use any type of wires such as 
modems used over an ISDN (Integrated Services Digital Network) line, ASDL 
(Asymmetric Digital Subscriber Line), modems which use frame relay communication, 
wireless modems such as a radio frequency modem, a fiber optic modem, or a device 
which uses infrared light waves). Further, a business office device 268 is connected to the 
computer 266. As an alternative to the business office device 268 (and any other device 
illustrated in Figure 5), a different type of machine may be monitored or controlled such 
as a digital copier, any type of appliance, security system, or utility meter such as an 
electrical, water, or gas utility meter, or any other device discussed herein. 
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[p66] Also illustrated in Figure 5 is a firewall 50-3 connected to a network 274. The 

network 274 may be implemented as any type of computer network, (e.g., an Ethernet or 
token-ring network). Networking software which may be used to control the network 
includes any desired networking software including software commercially available 
from Novell or Microsoft. The network 274 may be implemented as an Intranet, if 
desired. A computer 272 connected to the network 274 may be used to obtain information 
from a business office device 278 and generate reports such as reports showing problems 
which occurred in various machines connected to the network and a monthly usage report 
of the devices connected to the network 274. In this embodiment, a computer 276 is 
connected between the business office device 278 and the network 274. This computer 
receives communications from the network and forwards the appropriate commands or 
data, or any other information, to the business office device 278. Communication 
between the business office device 278 and the computer 276 may be accomplished using 
wire-based or wireless methods including, but not limited to radio frequency connections, 
electrical connections and light connections (e.g., an infrared connection, or a fiber optics 
connection). Similarly, each of the various networks and intranets illustrated in Figure 5 
may be established using any desired manner including through the establishment of 
wireless networks such as radio frequency networks. The wireless communication 
described herein may be established using spread spectrum techniques including 
techniques which use a spreading code and frequency hopping techniques such as the 
frequency hopping wireless technique which is disclosed in the Bluetooth Specification 
(available at the world wide web site www.bluetooth.com), which is incorporated herein 
by reference. 
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[p67] Another sub-system illustrated in Figure 5 includes a firewall 50-4, an intranet 260- 
4, a computer 282 connected thereto, a business office appliance 285 and a copier 286. 
The computer 282 may be used to generate reports and request diagnostic or control 
procedures. These diagnostic and control procedures may be performed with respect to 
the business office appliance 285 and the copier 286 or any of the other devices illustrated 
in or used with Figure 5. While Figure 5 illustrates a plurality of firewalls, the firewalls 
are preferable but optional equipment and therefore the invention may be operated 
without the use of firewalls, if desired. 

[p68] Figure 6A illustrates a Device/ Appliance 300 connected to a typical e-mail exchange 
system which includes components 302, 304, 306, 308, 310, 312, 314, 316, and 318 
which may be implemented in a conventional manner and are taken from Figure 28.1 of 
Stevens, above. A computer 302 interfaces with any of the application units 300 
described herein. While Figure 6 A illustrates that the Device/Appliance 300 is the sender, 
the sending and receiving functions may be reversed in Figure 6A. Furthermore, if 
desired, the user may not be needed to interface with the Device/Appliance 300 at all. The 
computer interface 302 then interacts with a mail agent 304. Popular mail agents for Unix 
include MH, Berkeley Mail, Elm, and Mush. Mail agents for the Windows family of 
operating systems include Microsoft Outlook and Microsoft Outlook Express. At the 
request of the computer interface 302, the mail agent 304 creates e-mail messages to be 
sent and, if desired, places these messages to be sent in a queue 306. The mail to be sent 
is forwarded to a Message Transfer Agent (MTA) 308. A common MTA for Unix 
systems is SendmaiL Typically, the message transfer agents 308 and 312 exchange 
communications using a TCP/IP connection. Notably, the communication between the 
message transfer agents 308 and 312 may occur over any size network (e.g., WAN or 
LAN). Further, the message transfer agents 308 and 312 may utilize any communication 
protocol. In the present invention, steps 302 and 304 reside in the library to monitor the 
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application unit's usage. 

[p69] From the message transfer agents 312, e-mail messages are stored in user mailboxes 
314 which are transferred to the mail agent 316 and ultimately transmitted to the user at a 
terminal 318 which functions as a receiving terminal. 

[p70] This "store-and-forward" process avoids the sending mail agent 304 from having to 
wait until establishment of the direct connection with the mail recipient. Because of 
network delays, the communication could take a substantial amount of time during which 
the application would be unresponsive. Such an unresponsiveness is generally 
unacceptable to users of the application unit. By using e-mail as the store-and-forward 
process, retransmission attempts after failures occur automatically for a fixed period of 
time (e.g., three days). In an alternate embodiment, the application can avoid waiting by 
passing communicating requests to one or more separate threads. Those threads can then 
control communication with the receiving terminal 318 while the application begins 
responding to the user interface again. In yet another embodiment in which a user wishes; 
to have communication completed before continuing, direct communication with the 
receiving terminal is used. Such direct communication can utilize any protocol not 
blocked by a firewall between the sending and receiving terminals. Examples of such 
protocols include FTP and HTTP. 

[p71] Public WANs, such as the Internet, are not considered to be secure. Therefore, 

messages transmitted over the public WANs (and multi-company private WANs) should 
be encrypted to keep the messages confidential. Encryption mechanisms are known and 
commercially available which may be used with the present invention. For example, a C 
library function, crypto, is available from Sun Microsystems for use with the Unix 
operating system. Other encryption and decryption software packages are known and 
commercially available and may also be used with this invention. One such package is 
PGP Virtual Private Network (VPN) available from Network Associates. Other VPN 
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software is available from Microsoft Corporation. 

[p72] As an alternative to the general structure of Figure 6 A, a single computer may be 
used which functions as the computer interface 302, the mail agent 304, the mail queue 
306 and the message transfer agent 308. As illustrated in Figure 6B, the 
Device/Appliance 300 is connected to a computer 301 which includes the message 
transfer agent 308. 

[p73] A further alternative structure is shown in Figure 6C in which the message transfer 
agent 308 is formed as part of the Device/Appliance 300. Further, the message transfer 
agent 308 is connected to the message transfer agent 312 by a TCP/IP connection 310. In 
the embodiment of Figure 6C, the Device/Appliance 300 is directly connected to the 
TCP/IP connection 310 and has an e-mail capability. One use of the embodiment of 
Figure 6C includes using a facsimile machine with an e-mail capability (defined in RFC 
2305 (a simple mode of facsimile using Internet mail)) as the Device/ Appliance 300. 

[p74] Figure 6D shows a system where an appliance or a device does not itself have the 
capability to receive directly e-mail, but uses the POP3 protocol to retrieve the received 
mail from mail server. 

[p75] Figure 7 illustrates an alternative implementation of transferring mail and is based 
on Figure 28.3 of Stevens. Figure 7 illustrates an electronic mail system having a relay 
system at each end. The arrangement of Figure 7 allows one system at an organization to 
act as a mail hub. In Figure 7, there are four MTAs connected between the two mail 
agents 304 and 316. These MTAs include local MTA 322A, relay MTA 328 A, relay 
MTA 328B, and local MTA 322D. The most common protocol used for mail messages is 
SMTP (Simple Mail Transfer Protocol) which may be used with this invention, although 
any desired mail protocol may be utilized. In Figure 7, 320 designates a sending host 
which includes the computer interface 302, the mail agent 304, and the local MTA 322A. 
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The Device/Appliance 300 is connected to, or alternatively included within, the sending 
host 320. As another case, the Device/ Appliance 300 and host 320 can be in one machine 
where the host capability is built into the Device/ Appliance 300. Other local MTAs 322B, 
322C, 322E and 322F may also be included. Mail to be transmitted and received may be 
queued in a queue of mail 306B of the relay MTA 328 A. The messages are transferred 
across the TCP/IP connection 310 (e.g., an Internet connection or a connection across any 
other type of network). 

[p76] The transmitted messages are received by the relay MTA 328B and if desired, stored 
in a queue of mail 306C. The mail is then forwarded to the local MTA 322D of a 
receiving host 342. The mail may be placed in one or more of the user mailboxes 314 and 
subsequently forwarded to the mail agent 3 1 6 and finally forwarded to the user at a 
terminal 3 18. If desired, the mail may be directly forwarded to the terminal without user 
interaction. 

[p77] The various computers utilized by the present invention, including the computers 
266 and 276 of Figure 5, may be implemented as illustrated in Figure 8. Further, any 
other computer utilized by this invention may be implemented in a similar manner to the 
computer illustrated in Figure 8, if desired, including the service machine 254, computer 
272, and computer 282 of Figure 5. However, not every element illustrated in Figure 8 is 
required in each of those computers. In Figure 8, the computer 360 includes a CPU 362 
which may be implemented as any type of processor including commercially available 
microprocessors from companies such as Intel, AMD, Motorola, Hitachi and NEC. There 
is a working memory such as a RAM 364, and a wireless interface 366 which 
communicates with a wireless device 368. The communication between the interface 366 
and device 368 may use any wireless medium (e.g., radio waves or light waves). The 
radio waves may be implemented using a spread spectrum technique such as Code 
Division Multiple Access (CDA) communication or using a frequency hopping technique 
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such as that disclosed in the Bluetooth specification. 

[p78] There is a ROM 370 and a flash memory 371, although any other type of non- 
volatile memory (e.g., EPROM, or an EEPROM) may be utilized in addition to or in 
place of the flash memory 371 . An input controller 372 has connected thereto a keyboard 
374 and a mouse 376. There is a serial interface 378 connected to a serial device 380. 
Additionally, a parallel interface 382 is connected to a parallel device 384, a universal 
serial bus interface 386 is connected to a universal serial bus device 388, and also there is 
an IEEE 1394 device 400, commonly referred to as a fire wire device, connected to an 
IEEE 1394 interface 398. The various elements of the computer 360 are connected by a 
system bus 390. A disk controller 396 is connected to a floppy disk drive 394 and a hard 
disk drive 392. A communication controller 400 allows the computer 360 to 
communicate with other computers (e.g., by sending e-mail messages) over a telephone 
line 402 or a network 404. An I/O (Input/Output) controller 408 is connected to a printer 
410 and a hard disk 412, for example using a SCSI (Small Computer System Interface) 
bus. There is also a display controller 416 connected to a CRT (Cathode Ray Tube) 414, 
although any other type of display may be used including a liquid crystal display, a light 
emitting diode display, a plasma display, etc. 

[p79] One feature in the present invention is to monitor how a user uses a target 

application of an application unit. The term application unit in this instance refers to a 
system which a user interacts with and controls. A "target application" refers to a user 
controlled system that controls the application unit. For example, an application unit may 
typically be a computer and a target application may then be a software program, e.g. a 
word processor, running on the computer which a user operates, for example by moving a 
pointer on a computer screen and "clicking" on certain command icons to cause the 
software program to perform certain functions. In this sense, an application unit in the 
present invention can refer to any of workstations 17, 18, 20, 22, 56, 62, 68, 74, 42 shown 
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in Figure 1 running a software program, the computer 301 shown in Figure 6B running a 
software program, etc. An application unit can also refer to an image forming device such 
as any of the digital image forming apparatus 24, facsimile machine 28, and printer 32 in 
Figures 1 and 2. In this instance, each of these device application units includes a user 
interface, such as operation panel 174 (see Fig. 3), which a user interacts with and utilizes 
to control the device application unit. The present invention can monitor a user selecting 
controls on such an operation panel. As a further example, the application unit could also 
be an appliance, such as a microwave oven, with an operation panel. An application unit 
can also refer to any other device, including software, with which a user interacts, and in 
this case the target application may refer to only one feature of the software which the 
user interacts with. 

[p80] One feature of the present invention is to monitor the user's usage of such a target 
application of an application unit, and to communicate data of the monitored usage. This 
data will typically be transmitted by e-mail by the computer interface 302 of Figure 6 A, 
or the computer 301 of Figure 6B or the Device/Appliance 300 of Figure 6C. This data of 
a user's usage of a target application of an application unit can then be utilized in many 
ways, for example in improving software development, in monitoring usage of a device 
(e.g., an image forming device), discovering user difficulties with appliances and 
software, and finding most frequently used features of application units. 

[p81] Figure 9 shows various elements of the present invention. More particularly, Figure 
9 shows an Device/Appliance 300 including target applications 510, 512 and 513. The 
user interface 510 is an interface for a user to control the appliance or device. As 
discussed above, in one common instance, the target appliance 300 may be a software 
program running on one of the workstations 17, 18, 20, 22 (Figure 1) of the present 
specification. In this instance, the user interface 510 may be a display on a monitor of one 
of these workstations. In such a case, the monitoring system 515 may monitor the user 



Page 25 of 79 



behavior of clicking the selected menu. Another application may be that the appliance 
300 is a copier where "application 2" (512) is a sorting of the multiple copies. Both User 
interface 510 and "Application 2" (512) would send event messages to Monitoring 
System 515 to be logged. The Monitoring System 515 is implemented either only in 
hardware or using a combination of hardware and software where the combination 
includes at least one computer readable medium. Examples of computer readable media 
are compact discs 119, hard disks 1 12, floppy disks, tape, magneto-optical disks, PROMs 
(EPROM, EEPROM, Flash EPROM), DRAM, SRAM, SDRAM, etc. Stored on any one 
or on a combination of computer readable media, the present invention includes software 
for controlling both the hardware and for enabling the system to interact with a human 
user. Such software (in the form of computer code devices) may include, but is not 
limited to, device drivers, operating systems and user applications, such as development 
tools. Such computer readable media further includes the computer program product of 
the present invention for monitoring and controlling an application unit. The computer 
code devices of the present invention can be any interpreted or executable code 
mechanism, including but not limited to scripts, interpreters, dynamic link libraries, 
classes (e.g., Java or C++), packages (e.g., Java or C++) and complete executable 
programs. 

[p82] Another illustrative embodiment of Figure 9 is an office device such as a digital 
copier where Application 1 (510) is the aforementioned user interface. Application 2 
(512) is the software error tracking system to monitor the internal error conditions of the 
software system. Application 3 (513) is the mechanical error tracking system to monitor 
the mechanical error condition such as jam and toner out. All of the applications are using 
the Monitoring System (515) and Sending Block (520). As a further example, and as 
noted above, the Device/Appliance 300 may be an image forming device such as the 
digital image forming apparatus 26, facsimile machine 28, or printer 32 also shown in 
Figure 1 . In this instance, the user interface 510 may take the form of an operation panel 
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(e.g., operation panel 174 in Fig. 3) with a plurality of keys and/or a touch screen which a 
user operates to control the image forming device. When the Device/ Appliance 300 in 
Figure 9 is an image forming device with a user interface 510, the present invention can 
monitor the commands that a user selects. 

[p83] At a designated time, the logged data of the events is then sent to the sending block 
520, which then communicates such monitored event data to a designated party. The 
monitoring and logging DLL 515 can be implemented in the device including the 
Device/Appliance 300 or in another system control element. The protocol processing 
system can also be implemented in the device including the application unit in Figure 6C, 
or can also be implemented in the computer 301 in Fig. 6B to which the application unit 
is attached. The present invention can also take the form of computer control codes 
recorded on a computer readable medium. 

[p84] One illustrative embodiment of such a user interface 5 1 0 used with a digital image 
forming apparatus 26, facsimile machine 28, or printer 32 is shown in Figure 1 1. In that 
embodiment, the present invention monitors each time a user presses one of the control 
buttons on the operation panel and logs the usage data of such a user usage for subsequent 
communication. 

[p85] As shown in Figure 1 1 , such an operation panel 700 may include a touch screen 705 
on which various commands may appear which an operator can select by touching 
different portions of the touch screen 705. The operation panel 700 may also include a 
10-key pad 710 and various other control buttons 715. In the case of an image forming 
device, the control buttons 715 may be commands for selecting a paper size, changing a 
magnification, changing a darkness of a desired image, etc. 
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[p86] When the Device/ Appliance 300 in Figure 9 is an image forming device and the user 
interface 510 corresponds to the operation panel 700 as shown in Figure 1 1, the present 
invention can monitor the commands (shown in Figure 1 1) that a user selects. The 
operation panel 700 shown in Figure 1 1 may, with modifications, also be an operation 
panel for a user-controlled appliance such as a microwave oven, VCR, digital camera, 
cellular phone, palm top computer, etc. 

[p87] Figures 10 and 1 1 show examples of the Device/Appliance 300 and user interface 
510 of Figure 9 to which the present invention can be applied. As would be readily 
apparent to those of ordinary skill in the art, the present invention is directed to various 
types of application units including various types of user interfaces. The present invention 
is applicable to any device to be monitored which includes a user interface. 

[p88] Figure 12 shows the general event management architecture of the system that can 
be implemented as any one, or a combination of, a dynamic linked library (DLL), a 
script, a Java or C++ class, a C library or routine, etc. The remainder of this discussion 
describes the implementation in terms of a DLL. In general, an application 510 
communicates through an interface 550. The interface 550 specifies the API for the event 
management architecture (e.g., how information is passed via a C function call to the 
object(s) in the System Manager 560 with the same names). The System Manager 
computer code device 560 manages the behavior of other computer code devices by using 
appropriate objects and their functions. Similarly, the Event Logger 565 records all the 
necessary information such as User ID, Application ID, Cumulative Session Number, 
Start Time, Duration and Sequence of Events with the elapsed times when requested 
through the system manager 560. The Event Logger supports functions including: 
initialize(), storeEvent (), stopMonitoringQ, and getEventDataQ. 
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[p89] The initialize function receives a string parameter for the Application ID. The 

System Manager 560 calls this function when startMonitoring is called by an application 
510. The function sets the Application ID, takes care of the Cumulative number of 
usages, reads the clock to store the start time in order to compute the elapse time and 
duration, and sets up the user information by examining the registry. 

[p90] The initialize function receives a string parameter for the Application ID. The 

System Manager 560 calls this function when startMonitoring is called by an application 
510. The function sets the Application ID, takes care of the Cumulative number of 
usages, reads the clock to store the start time in order to compute the elapse time and 
duration, and sets up the user information by examining the registry. 

[p91] After the application 510 has completed its usage monitoring, it calls the 

stopMonitoring function so that the duration can be computed. If multiple sessions are 
stored, this function stops the recording of a corresponding session. 

[p92] After initialization, the storeEvent() function can be called with a string parameter 
for the Event passed by recordEvent. The EventLogger 565 stores the event string and the 
elapsed time from the start time (recorded during the initialize() function call). 

[p93] The EventLogger 565 also provides access to a getEventData function. If the 
stopMonitoring was not previously called (i.e., the current session's duration field is 
undefined), the monitoring is stopped by calling the stopMonitoring function. The 
stopMonitoring function computes the duration of the current session. The getEventData 
function returns an abstract class with the access functions shown in Figure 12B. The 
abstract class facilitates extensions for multiple sessions. 
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[p94] The Format And Protocol Information Base System 570 (implemented as any one or 
a combination of package, DLL, static library, etc.) stores the format and protocol 
information and checks the combination of formats and protocols to determine the valid 
combinations. To facilitate the storage process, the storeFormatAndProtocol function 
accepts two parameters (i.e., one for format and one for protocol). The function checks to 
ensure that the parameters are a valid combination. 

[p95] The component 570 also includes a getFormatAndProtocolVector function returns a 
format and associated vector of protocols. In one embodiment, the function performs 
error checking. For example, if a protocol allows only one format to be sent, then the 
format should be the last format in the function call of selectFormatProtocol. The return 
value is a boolean value where true indicates that valid parameters were returned and 
false indicates that no more data is available. The return parameters are int and vector of 
int. The first int refers to the format while the vector of int refers to the vector of 
protocols for the format. When there is no selectFormatProtocol function call, the 
getFormatAndProtocolVector returns the default setting. Also would be evident, other 
collections (e.g., a list template) may be used in place of a vector. 

[p96] The Data Format Processor 575 is responsible for formatting event data into a 

specified format. One exemplary function is the formatEventData function that receives a 
pointer to the abstract class EventData. The return value is a pointer to the abstract class 
FormattedEventData. Generally, interface to the FormattedEventData abstract class is 
defined as in Figure 12C. 

[p97] The Protocol Processor 580 is responsible for outputting the formatted event data 
through the specified protocol. In one embodiment, the processor 580 also encrypts the 
body of message. To output the data, the processFormattedData function is called with an 
input pointer to the abstract class FormattedEventData. The function returns a boolean 



Page 30 of 79 



value where "true" represents no errors, and "false" represents the existence of an error 
while processing the formatted data. 

[p98] The System 585 supplies important information and persistent information across 
the execution of the DLL. Some of the important information is timer information 
through the library call. The registry to keep the necessary information is another 
important component of the System 585. Many registry entries are set up at installation 
time. An exemplary structure for the registry is: 

[p99] HKEY LOCAL MACHINE -- SOFTWARE -- RicohMonitor XXX 
^ (ApplicationID) 

4= [pi 00] Where XXX represents the Application ID, the following variables are placed in 

Iti the registry under XXX tree: CumulativeUsage, UserlD, SMTP Server, Recipients, 

yj From, FTP Server, FTP User, FTP Password, FTP Target Path etc. In one embodiment, 

3 CummulativeUsage is an integer, and the rest of the variables are strings. 

72 [pi 01] Figure 13 shows an exemplary calling sequence of various computer code devices 

21 according to the present invention. The application software sets up the Application ID 

and starts the monitoring computer code device. When the events to be monitored 
happen, the application sends a message to the monitoring computer code device with 
the event name so that monitoring computer code device will keep track of the name of 
event and the timing. When the application no longer needs to monitor any activities, 
the application sends a command to select the format and protocol to be used to send the 
monitored information. The application then calls the stopMonitoring function, either 
explicitly or implicitly, as described below. Although Figure 13 describes sending the 
monitored information each time an application stops monitoring, in an alternate 
embodiment, information is sent only upon a secondary event happening (e.g., elapsed 
time or after a number of events or monitoring sessions have occurred). 
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[pi 02] Figure 14 describes the process of sending the monitored information (e.g., when 
the monitoring stops as shown in Figure 13). After the stopMonitoring request has 
propagated from the Target Application (through the CMonitorSeqApp (in step 1)) to 
the CMonitorManager (in step 2) which passes the request to the EventLogger system 
(in step 3). The CMonitorManager coordinates subsequent communication between the 
other computer code devices. The first such communication is in response to a 
getEventData request made by the CMonitorManager. In step 5, CMonitorManager 
obtains a format and associated vector of protocols from 
CformatAndProtocolInformationBase. Later, step 6, entitled 

"CreateDataFormatProcessor," creates the data formatter for the selected formatting that 
is used to format the monitored event data in step 7. Step 8 obtains the protocol 
processor specified by the application software before stopping monitoring. Together, 
steps 6 and 8 show that the formatters and protocol processors can be created 
dynamically (i.e., only when they are needed). In addition, created protocol processors 
can be cached in the CProcessorBuilder. 

[p 1 03] Figure 1 5 shows the map data structure used for creating the DataFormat 

Processor. A map includes at least one (key, value) pair. By using a key (corresponding 
to one of the possible data formats) as an index value into the map, the system selects a 
corresponding pointer to a function that creates the data formatter that will transform the 
monitored event data into the specified data format. When the specified format is sent to 
the ProcessorBuilder in Figure 14, the corresponding value in the map for the format is 
the function pointer to create the formatter. The function pointed by the pointer is to 
create the requested data formatter. Therefore, the formatter itself is not actually created 
until the function pointed to by the pointer is executed. In addition, the class returned by 
this function is the abstract class entitled "data formatter." Accordingly, the user of the 
class does not need to know the details of the returned formatter, just the abstract class 
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that defines its basic functions. 

[pi 04] Figures 16 A and 16B are exemplary code embodiments corresponding to the 

Figure 14. Step 4 in the source code correspond to getting the specified formatter (step 6 
of the Figure 14) while step 5 of the source code formats the data (step 7 of the Figure 
14). 

[pl05] While the above discussion has generally focused on using a single protocol and/or 
a single data format, in an alternate embodiment, the present invention utilizes plural 
protocols and/or plural data formats. Those protocols and formats can include, but are 
not limited to any of the protocols and formats discussed herein. Exemplary formats 
include, but are not limited to, uncompressed or compressed versions of any one of: un- 
delimited text, SGML, XML, HTML, csv format, and binary. This enhances the number 
of possible ways that data can be transferred to support the monitoring of the present 
invention. Accordingly, one implementation of the application sends at least one 
(format, protocol) pair to be used by the computer code device (e.g., DLL). The 
computer code device checks that each pair is valid before storing it in the data structure 
of two maps. For example, if the format specifies the binary encoding of fixed format, 
but the protocol is SMTP with the plain text encoding in the mail body, the format and 
protocol are not a valid pair/combination. Before the monitored data are sent out, the 
computer code device checks if a selected protocol is restricted to support only one 
format. Two maps are used for this purpose. Then, the system utilizes the specified data 
format one at a time to generate the required format and sends out the generated data 
over all the protocol specified for this data format. 

[pi 06] The present invention is also applicable to implementations where two different 
kinds of parameters are specified multiple times where the first parameter processing is 
more costly than the second parameter processing. In addition, the some second 
parameter values may be restricted to supporting only one first parameter value that is 
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specified last. In such a case, the present invention technique can be utilized to process 
the system efficiently. 

[pi 07] Figure 17 shows the map data structure (using (key, value) pairs) used for creating 
and caching the protocol processor. In one embodiment, for a given formatted event 
data, multiple protocols may need to send the same event data. Likewise, the same 
protocol may be requested to send the same data using different data formats. As 
discussed above, the key of each pair specifies a protocol (e.g., SMTP, FTP or HTTP) to 
be used. The value of the map is itself a second pair (x,y), where x is a pointer to the 
protocol processor object, and where y is a pointer to the function that creates the 
protocol processor. This map is initialized to contain the keys and values with the x 
value being assigned a flag value (e.g., zero). When a particular protocol is requested, 
the x value corresponding to the specified key is checked. If the x value is zero, the 
function pointed to by y value is executed. That execution creates the protocol 
processor, and the pointer to the created object is stored in the x value. Then, the newly 
created or subsequently stored pointer to the object is then returned as a pointer to the 
abstract class. Step 6 of Figures 16A and 16B (corresponding to step 8 of Figure 14) 
illustrates an exemplary code fragment that calls the createProtocolProcessor function. 
The createProtocolProcessor function returns a pointer to the abstract protocol processor 
object (identified by the return type "CAbsProtocolProcessor *"). Step 7 of Figure 16B 
(corresponding to the step 9 of Figure 14) shows sending monitored information in a 
requested format. 

[pi 08] Figure 18A shows the function list and the attributes of the CProcessorBuilder 
Class according to one embodiment of the present invention. The public function 
createDataFormatProcessor receives the specification for the Data Formatter and returns 
the pointer to the specified Data Formatter object in the abstract class type. The public 
function createProtocolProcessor function receives the specification for the Protocol 
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Processor and returns the pointer to the specified Protocol Processor in the abstract class 
type. The m j>DataFormatter attribute of the class is used to cache the specified data 
formatter in the class. The other two map attributes show the structure shown in the 
Figures 15 and 17. The function definition section shows the steps used by the various 
functions declared in the function list. 

[pi 09] Figure 19 illustrates three exemplary steps that pass the format and protocol 

parameters from the Target Application to the Format and Protocol Information Base 
System to enable plural protocols and/or formats to be used. Similar to transferring a 
stopMonitoring request in Figure 14, Figure 19 shows how a selectFormatProtocol 
request is passed from the Target Application through the CMonitorSeqApp to the 
CMonitorManager. The CMonitorManager converts the request into a 
storeFormatAndProtocol request that is passed on to the Format and Protocol 
Information Base System, thereby storing the format and protocol information. 
Although the parameters are illustrated as integers, any type can be used that uniquely 
specifies the format and protocol. As would be evident, the functions can return either 
nothing or an error code. 

[pi 10] Figure 20 shows relationships of the CFormatProtocolCombinationCheck class 610 
and the CProtocolRestrictionCheck class 620 used within the Format And Protocol 
Information Base System. Generally, the CFormatProtocol_InformationBase interface 
600 (described in more detail with reference to Figures 23A and 23B) keeps track of the 
specified formats and protocols. That interface 600 uses the (1) 
CFormatProtocolCombinationCheck class 6 1 0 and (2) the CProtocolRestrictionCheck 
class 620 for (1) verifying requested combinations and (2) checking for restrictions on 
the protocols, respectively. 
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[pill] Figure 21 describes the process by which the system manager 560 verifies whether 
a specified format and protocol combination is valid. A storeFormatAndProtocol request 
from the system manager 560 is initially handled by the 

CFormatProtocol_InformationBase interface 600. Using the relationships illustrated in 
Figure 20, that interface 600 converts the request to an 
isFormatProtocolCombinationOK request that is sent on to the 

CFormatProtocolCombinationCheck class 610. If that class 610 returns "true," then the 
combination is valid; otherwise, the class 610 returns false indicating that the 
combination is invalid. When the combination is valid, the two values are stored into 
two different maps specified in the Figure 23 A. 

[pi 12] Figure 22 describes the process of returning the format and list of protocols. In 
Figure 22, int and vector are exemplary output parameters, but other implementations 
may use other containers (e.g., the list template of the standard template library) to 
facilitate the restriction check. Generally, the system manager 560 sends a 
getFormatAndProtocolVector request to the CFormatProtocol_InformationBase 
interface 600. Using the relationships illustrated in Figure 20, that interface 600 converts 
the request to a getFormatProtocolVectorMapAfterCheckingProtocolRestriction request 
that is sent on to the CProtocolRestrictionCheck class 620. 

[pi 13] Figure 23 A is an exemplary class definition of CFormatProtocolJnformationBase 
interface/class. The functions, storeFormatAndProtocol and 

getFormatAndProtocolVector, are public functions used by the System Manager 560 
computer code device (an object of CMonitorManager class). Two map structures keep 
the specified formats and protocols passed through the function, 
storeFormatAndProtocol, after checking the validity of the combination of the format 
and the protocol through the object, mFormatProtocolCombinationCheck of 
CFormatProtocolCombinationCheck class. The class also contains the object, 
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m_ProtocolRestrictionCheck of CProtocolRestrictionCheck class. The flag, 
m_bFirstGetCall is used to call the function in the m_ProtocolRestrictionCheck when 
the function getFormatAndProtocolVector is called for the first time. The attribute, 
mJFormatProtocolVectorMapIterator, is used by the getFormatAndProtocolVector 
function to iterate over the m_FormatProtocolVectorMap. Figure 23B shows the steps 
for three main functions in the CFormatProtocol_InformationBase class 600. 

[pi 14] Figures 24 A and 24B show the class definition of 

CFormatProtocolCombinationCheck class 610. The main responsibility of the class 610 
is to check whether a specified format and protocol combination is valid. The map, 
m_CombinationMartix, contains the information of the valid combination that is 
initialized by the function initMatrix. 

[pi 15] Figures 25 A, 25B, and 25C show the class definition of the 

CProtocolRestrictionCheck class 620. The m__bOneFormatRestriction attribute specifies 
whether the information is restricted to a single format. Other types of restrictions could 
be implemented by adding other private functions and attributes. An exemplary 
restriction algorithm for the present invention is illustrated in Figures 25B and 25C 
(showing the steps in the private function oneFormatRestriction). 

[pi 16] Obviously, numerous modifications and variations of the present invention are 

possible in light of the above teachings. It is therefore to be understood that, within the 
scope of the appended claims, the invention may be practiced otherwise than as 
specifically described herein. 
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Deposit of Computer Program Listings 

Not Applicable 
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What is Claimed is: 

[cl] A computer program product, comprising: a computer storage medium and a 
computer program code mechanism embedded in the computer storage medium for 
controlling a combination of a protocol and a format used to communicate event data 
between a remote receiver and at least one of a device, an appliance, an application and an 
application unit, the computer program code mechanism comprising: a first computer code 
device configured to select a protocol to transfer event data between the remote receiver 
and the at least one of a device, an appliance, an application and an application unit; a 
second computer code device configured to select a first format to transfer event data 
between the remote receiver and the at least one of a device, an appliance, an application 
and an application unit; and a third computer code device configured to determine if the 
protocol selected by the first computer code device is compatible with the first format 
selected by the second computer code device. 

[c2] The computer program product as claimed in claim 1, further comprising a fourth 
computer code device configured to select a second format to transfer event data between 
the remote receiver and the at least one of a device, an appliance, an application and an 
application unit if the first format is not compatible with the protocol selected, wherein the 
third computer code device is further configured to determine if the protocol selected by 
the first computer code device is compatible with the second format selected by the fourth 
computer code device. 

[c3] The computer program product as claimed in claim 1, further comprising: a fourth 
computer code device configured to select a second format to transfer event data between 
the remote receiver and the at least one of a device, an appliance, an application and an 
application unit after selecting the first format; and a fifth computer code device configured 
to transmit data to the remote receiver from the at least one of a device, an appliance, an 
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application and an application unit only using the second format if the protocol supports 
only one format at a time. 



[c4] The computer program product as claimed in claim 1, further comprising: a fourth 
computer code device configured to select a second format to transfer event data between 
the remote receiver and the at least one of a device, an appliance, an application and an 
application unit after selecting the first format; and a fifth computer code device configured 
to transmit data to the remote receiver from the at least one of a device, an appliance, an 
application and an application unit sequentially using the first and second formats if the 
protocol supports plural formats at a time. 

[c5] The computer program product as claimed in claim 1, further comprising: a fourth 
computer code device configured to select a second format to transfer event data between 
the remote receiver and the at least one of a device, an appliance, an application and an 
application unit after selecting the first format; and a fifth computer code device configured 
to transmit data to the remote receiver from the at least one of a device, an appliance, an 
application and an application unit in parallel using the first and second formats if the 
protocol supports plural formats at a time. 

[c6] The computer program product as claimed in claim 1, wherein: the first computer 
code device comprises a fourth computer code device configured to store a first indicator, 
corresponding to the protocol selected, in a map entry of a map; and the second computer 
code device comprises a fifth computer code device configured to store a second indicator, 
corresponding to the first format, in the map entry. 

[c7] The computer program product as claimed in claim 6, wherein the third computer 
code device comprises a sixth computer code device configured to compare the first and 
second indicators stored in the map against values in a data structure corresponding to at 
least one compatible format for a specified protocol. 
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[c8] The computer program product as claimed in claim 6, wherein the third computer 
code device comprises a sixth computer code device configured to compare the first and 
second indicators stored in the map against values in a data structure corresponding to at 
least one compatible protocol for a specified format. 

[c9] The computer program product as claimed in claim 6, wherein the third computer 
code device comprises a sixth computer code device configured to iterate over values in a 
data structure corresponding to at least one compatible protocol for a specified format. 

[cl 0] The computer program product as claimed in claim 6, wherein the third computer 
code device comprises a sixth computer code device configured to iterate over values in a 
data structure corresponding to at least one compatible format for a specified protocol. 

[c 1 1 ] The computer program product as claimed in claim 1 , wherein at least one of the 
first through third computer code devices comprise a library of code shared between first 
and second applications. 

[c 1 2] The computer program product as claimed in claim 1 , wherein at least one of the 
first through third computer code devices comprise a dynamically linked library of code 
shared between first and second applications. 

[c 1 3] A computer-implemented method for controlling a combination of a protocol and a 
format used to communicate event data between a remote receiver and at least one of a 
device, an appliance, an application and an application unit, comprising: selecting a 
protocol to transfer event data between the remote receiver and the at least one of a 
device, an appliance, an application and an application unit; selecting a first format to 
transfer event data between the remote receiver and the at least one of a device, an 
appliance, an application and an application unit; and determining if the protocol selected 
is compatible with the first format selected. 
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[cl4] The method as claimed in claim 13, further comprising: selecting a second format to 
transfer event data between the remote receiver and the at least one of a device, an 
appliance, an application and an application unit if the first format is not compatible with: 
the protocol selected; and determining if the protocol selected is compatible with the 
second format selected. 

[cl5] The method as claimed in claim 13, further comprising: selecting a second format to 
transfer event data between the remote receiver and the at least one of a device, an 
appliance, an application and an application unit after selecting the first format; and 
transmitting data to the remote receiver from the at least one of a device, an appliance, an 
application and an application unit only using the second format if the protocol supports 
only one format at a time. 

[cl6] The method as claimed in claim 13, further comprising: selecting a second format to 
transfer event data between the remote receiver and the at least one of a device, an 
appliance, an application and an application unit after selecting the first format; and 
transmitting data to the remote receiver from the at least one of a device, an appliance, an 
application and an application unit sequentially using the first and second formats if the 
protocol supports plural formats at a time. 

[cl7] The method as claimed in claim 13, further comprising: selecting a second format to 
transfer event data between the remote receiver and the at least one of a device, an 
appliance, an application and an application unit after selecting the first format; and 
transmitting data to the remote receiver from the at least one of a device, an appliance, an 
application and an application unit in parallel using the first and second formats if the 
protocol supports plural formats at a time. 
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[cl 8] The method as claimed in claim 13, further comprising: storing a first indicator, 
corresponding to the protocol selected, in a map entry of a map; and storing a second 
indicator, corresponding to the first format, in the map entry. 
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Return Value 


Function Name 


Description 


bool 


getNextSession 


Returns false when there is no more session* 

true otherwise 


string 


getFileName 


Returns file name for the EventData 


map<string, string> 


getSessionlnformation 


Returns the map. Keys are UserlD, 
AppIicationID, CumulativeSessionNumber, 
StartTime, and Duration. 


map<string, 
vector<string» 


getSessionEventData 


Returns the map. Keys are EventName and 
EventTiming. The values of EventTiming 
vector are in the unit of 10th of a second 
converted from unsigned integer to string. 



Figure 12B 
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Return Value 


Function Name 


Description 


bool 


getNextLine 


Returns one line of string data as an out 
parameter string. The function returns true if 
there is a line; false if no more line exists with 
empty string. 


string 


getFileNameWithSuffix 


Returns file name for the data with suffix if 
applicable 



Figure 12C 
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void CMonitorManager: : 3topMonitoring ( ) 
{ 

TRACE ("CMonitorManager: :stopMonitoring \n") ; 

// 1. calls the function stopMonitoringf) of 
/ / CUsageLogger . 

m_UsageLogger. stopMonitoring ( } ; 

// 2. calls the function getEventDataO of 

// CUsageLogger. This function returns the usage 

// information, CAbsEventData, to CMonitorManager. 

CAbsEventData * loc_pAbs Event Data * m__Os ageLog get. ge t Even tData( > ; 

// 3. calls the function getFo rmatAndProtocol vector ( ) 
// of CFormatProtocol_InformationBase. This function 

// returns the following to CMonitorManager: an int for 

// the data format, a list<int> for the communication 

// protocols, and a bool to indicate if the return 

// values (format and protocol) are valid. 



int loc_nFonaat; 

list<int> loc_Protocol Vector; 

CProcessorBuilder loc Process orBuilder; 



while (m_FormatProtocol_Inf o mat ionBase. get Forma tAndPro toco IVec tor ( 
loc_nFormat, loc_ ProtocolVector) ) \ 

// 4. calls the function creat eDataFormat Process or ( } 
// of CProcessorBuilder. CMonitorManager passes an 

// int for the data format into this function. This 

// function returns the data format processor, 

// CAbsDataFonnatter, to CMonitorManager. 

CAbsDataFormatter * locjpAbsDataFormatter - 

loc_ProcessorBuilder.createDataFormatProcessor {loc_nFormat) ; 

// 5. calls the function f ormatEventData ( ) of 
// CAbsDataFormatter. CMonitorManager passes the 

// usage information, CAbsEventData, into this 

// function. This function returns the formatted 

// usage information, CAbsFormattedEventData, to 

/ / CMonitorManager . 



CAbsFormattedEventData + loc_pAbs Format tedEvent Data * 

loc_ - pAbsDataFormatter->f ormatEventData (loc_pAbsEventData) 

// 6. calls the function createProtocolProcessor ( } of 

// CProcessorBuilder. CMonitorManager passes an int 

// for the communication protocol into this function. 

// The int is the first int from the protocol vector, 

// list<int>. This function returns the protocol 

// processor, CAb3Protocol Processor, to CMonitorManager. 

for (list<int>: : iterator loc_ProtocolVectorlterator = 

loc_ProtocolVector. begin O ; loc_ProtocolvectorIterator ne 
loc ProtocolVector.endO ; loc ProtocolVectorlterator ++) { 



Figurel6A 
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CAbsProtocolProcessor * locjpAbsProtocolProcesaor - 
loc Process or Builder . createProtocolProcessor t 
* loc Protocoivectorlterator} ; 



// 7. calls the function processFormattedData <) of 
// CAbsProtocolProcessor. CMonitorManager passes the 

// formatted usage information, CAbsFormattedEventData, 

// into this function. This function returns a bool to 

// CMonitorManager to indicate if the usage information 

// was communicated using the protocol. 



loc__pAbsProtocolProcessor->processFormattedData ( 
loc_pAbsFormattedEventData) ; 



) 

// 8. steps 6 and 7 are repeated for each protocol, 
// int, in the protocol vector , list<int>. 

} 

// 9. steps 3 through 8 are repeated for each format 
// until the function g« t Format AndProtocolvect or ( } 

// returns NO to CMonitorManager. 

> 



Figure 16B 
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Author Avery Fong 

3.3 CProcessorBuilder Class Specification 



3 3 1 Function List 
public: 

CProcessorBuilderO; 

-CProccssorBuilderO; 

CAbsDataFormattcr* creatcDat«FonnatProccssor(int nwiFormat); 
CAbsProtocolProcessor* create ProtocolProcessor(int in_nProtocol), 

private: 

void toitDataFormatProcessorMapO, 
void initProtocolProccssorMapO; 

Include the following functions to create the different data format processors and protocol processors. 
CAbsDataFormattcr* crcatcComm aDataForm attcrO; 
CAbsDataFormattcr* crcatcXMLDataFormattcrO; 
CAbsProtocoIProcessor* crcatcSmtpProtocolProcessorO; 
CAbsProtocolProccssor* createFtpProtocolProccssorO; 
If new data formats or new protocols are added, then new functions to create them must be added. 

Include the following typedef declarations for the functions that create the data format processors and protocol processors, 
typedef CAbsDataFormattcr* (*DataFormatProcessorBuilder) 0, 
typedef CAbsProtocoIProcessor* (*ProtocolProcessorBuilder) 0; 



3.3.2 Class Attributes 



Type 


Attribute Name 


Description 


CAbsDataFormattcr* 


m_pDataFormatter 


This attribute member points to the data format processor object It is 
initialize to 0 in the constructor and the data format processor object is 
created by the function createDataForraatProcessorO- This function 
may be called multiple times so that it must delete the previous data 
format processor object pointed to by this attribute member before 
creating a new one. The destructor will delete the last data format 
processor object pointed to by this attribute member. 


map<int, 
DataFormatProcessorBuilder> 


mJE*rotocolProcessorMap 


This attribute member is a map of pointers to functions that create the 
data format processor. The key to this map is an int for the data format 

type. The value is a pointer to a function that creates the data format 
processor corresponding to the key. The pointers to the functions in the 
map are initialized in the function i nitDataForm alPro cessorMapO . 


map<mt, 
pair<CAbsProto col Processor* , 
ProtocolProcessorBuilder> > 


mProtocolProcessorMap 


This attribute member is a map of pointers to protocol processor objects 
and pointers to functions that create them. The key to this map is an int 

for the protocol processor type The value is a pair consisting of a 
pointer to the protocol processor object and a pointer to a function that 

creates the protocol processor object All the pointers to the protocol 
processor object are initialized to 0 and its corresponding functions arc 

intialized by the function initProtocolProcessorMapO- The protocol 
processor objects are created by the function createProtocotProcessorO. 
The destructor will delete all the protocol processor objects pointed to 

by the map. 



Figure 18A 
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3-3.3 Function Definitions 

////////////////////////////////////////////////////////////////////////// 



// function: CProcessorBuilder 
// Description: Constructor 
// Preconditions: None. 
// Postconditions: None. 

// Algorithm: 1. calls the private function 

// initDataFormatProcessorMap( } . 

// 2. calls the private function 

// initProtocolProcessorMapO • 

////////////////////////////////////////////////////////////////////////// 

////////////////////////////////////////////////////////////////////////// 
// Function: -CProcessorBuilder 
// Description: Destructor 
// Preconditions: None. 
// Postconditions: None. 

// Algorithm: 1. delete the object pointed to by m_j>DataFormatter . 

// 2. iterate through the map, m_ProtocolProcessorMap. 

// For each entry in the map, get the protocol 

// processor object pointed to by the pair and delete 

// the object. 

////////////////////////////////////////////////////////////////////////// 

////////////////////////////////////////////////////////////////////////// 
// Function: createDataFonnat Processor 

// Description: This function creates a data format processor 

// object. The data format processor object created 

// corresponds to the data format type in_nFonaat. 

// Preconditions: The data format type must be valid. 

// Postconditions: The pointer to the data format processor object, 

// m_pDataFormatter, cannot be 0. 

// Algorithm: 1. if m_pDataFormatter currently points to a data 

// format processor object, then delete the object. 

// 2. creates a new data format processor object by 

// calling the function in the map, 

// m_DataFormatProcessorMap, that corresponds to the 

// data format type, in_nFormat, and assign it to 

// m_j>DataFormatter . 

// 3. returns mjpDataFormatter. 

////////////////////////////////////////////////////////////////////////// 

////////////////////////////////////////////////////////////////////////// 

// Function: createProtocolProcessor 

// Description: This function creates a protocol processor object. 

// The protocol processor object created corresponds 

// to the protocol type in_nProtocol . 

// Preconditions: The protocol type must be valid. 

// Postconditions: The pointer to the created protocol processor object 

// cannot be 0. 

// Algorithm: 1. for the protocol type, in_nProtocol , get the 

// pair from the map that contains the pointer to 

// protocol processor object and its corresponding 

// pointer to the function that creates it. 

// 2. if the pointer to the protocol processor object 

// is 0, then use its corresponding function to create 

// it and assign it to the pointer in the map. Return 

// the pointer to the protocol processor object. 

// 3. if the pointer points to a protocol processor 

// object, then return this pointer. 



////////////////////////////////////////////////////////////////////////// 

Figure 18B 
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// Private 

// Function: initDataFormatProcessorMap 

// Description: This function initializes all the function pointers 

// in the map m_DataFormatProcessorMap. If new data 

// formats are added, then this function must be 

// modified. 

// Preconditions: None. 

// Postconditions: None. 

// Algorithm: 1. add entries to the map, m_DataFormatProcessorMap, 

// for each data format type. The key will be the 

// data format type and the value will be the pointer 

// to the corresponding function that creates the 

// data format processor. 

// 2. for data format type 1, the function pointer 

// points to createCommaDataFormatter Q . 

// 3. for data format type 2, the function pointer 

// points to createXMLDataFormatter (> . 

////////////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////////{//// 
// Private 

// Function: initProtocolProcessorMap 

// Description: This function initializes all the pairs of pointers 

// in the map m_ProtocolProcessorMap. If new protocols 

// are added, then this function must be modified. 

// Preconditions: None. 

// Postconditions: None. 

// Algorithm: 1. add entries to the map, m_ProtocolProcessorMap, 

// for each protocol type. The key will be the 

// protocol type and the value will be a pointer to 

// the protocol processor object and a pointer 

// to the corresponding function that creates the 

// protocol processor. All pointers to the protocol 

// processor obaects will be set to 0. 

// 2. for protocol type 1, the function pointer 

// points to createSmtpProtocol Processor { ) . 

// 3. for protocol type 2, the function pointer 

// points to createFtpProtocol Processor () . 

////////////////////////////////////////////////////////////////////////// 

/////////////////////////////////////////////////////////////////////r//// 

// Function: createCommaDataFormatter 

// Description: This function creates and returns a comma data 

// formatter object. 

// Preconditions: None. 

// Postconditions: The pointer to the created comma data formatter 

// object cannot be 0. 

// Algorithm: 1. creates and returns an object of the class 

// CCommaOat a Formatter . 

////////////////////////////////////////////////////////////////////////// 



////////////////////////////////////////////////////////////////////////// 



// 
// 
// 
// 
// 
// 

// Algorithm: 
// 



Function: 
Description: 

Preconditions : 
Postconditions : 



createXMLDataFormatter 

This function creates and returns an XML data 

formatter object. 

None. 

The pointer to the created XML data formatter 
object cannot be 0. 

1. creates and returns an object of the class 
CXMLDataFormat ter . 



////////////////////////////////////////////////////////////////////////// 



Figure 18C 
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// 
it 
it 
it 
it 
it 

// Algorithm: 

II 



Function: 
Description: 

Preconditions : 
Postconditions : 



create SmtpProtocol Processor 

This function creates and returns an SMTP protocol 

processor object. 

None. 

The pointer to the created smtp protocol processor 
object cannot be 0. 

1. creates and returns an object of the class 
CSmtp Protocol Processor . 



fiiiiitiiiiitiiiitiiiifiiiiiitiiiiimiiiiimtiiiiiiimmtiiimmmi 



iiiiiiiitfuitiniiiiiiiiifnmmmmmmmmmimmummm 



ft Function: 
// Description: 
II 

ft Preconditions: 
// Postconditions: 
II 

II Algorithm: 

// 



creat e Ftp P ro toco 1 Pr oces s o r 

This function creates and returns an FTP protocol 

processor object. 

None. 

The pointer to the created ftp protocol processor 
object cannot be 0. 

1. creates and returns an object of the class 
CFtpProtocolProcessor. 



tiiiifinitiiiifiiitiiitfiimmmmmmimmmmtiiimtmmii 



Figure 18D 
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Figure 20 



Page 70 of 79 



Svstam Manager 



56Q 



1: 9toreFormatAndProtocol 




600 



FormatPfotocolVectortlap 



QFQrmatProta?pi InftrmatlonBise 



^0 int. int 
yea & / 



At_9tep^ 3 and 4« store ^ 
th6 format and protocol 
in the map of Int !l9t<lrrt> 
of above where the first 
isthakey 



CFormaiPfQtoctilCombinatioi^hBfck 



2: IsFormatProtocolComblnationOK 



Figure 21 



Page 71 of 79 



560 



Sretam Marianar 




600 



J: getFormatAndProtocolVector 



inland vector are 
returnad as out 
parameters 



CFormatPmtocol li 




tase 



Foi-matProtocoWectorMap, ProtocolFormartVectorMap 



CProtocoiRestrictfortChetk 



T 

620 



getFoirnatProtocolVecto^ 

L 



The function passes tftetwc maps to verity the restriction er> 
protocol. FormatPrtrtocotVectorMap Is In and out The 
FormatProtocolVectofMap Id used for the return value. 
ProtcColFwmatVectofMa^-is k 



Figure 22 



Page 72 of 79 



CFormatProtocoMnformattonBase Class Specification 



Page 1 of 2 



Author Tetsuro Motoyama 

5,2 CFormatProtacol JnformitionBase Class Specification 

52A Function List 

public: 

CFormatProtocol InformationBasc{); 

-CForraatProtoco!_InformationBasc(); 

void storeFornwAndProtocoIflm in nFormat, int in_nProtoccI); 

bool gctFonnatAtidProtocotVectoi(mt & out_nFormat, lisfrcinO & out_Pratocol Vector); 

private: 

void setDefeuttFormatAndProtocoiO; 
5.2.2 Class Attributes 



Type 


Attribute Name 


Description 


mop<int, lbt<int> > 


raFormatProtocolVcctorMap 


The key ts a format value, and the list is the list of 
protocol values associated to the key. Because 
subscripting Q is not needed in this implementation, 
list is used fee die vector implementation. This map is 
used to return the necessary information for 
gctFormatAndProtocoTVector function 
Note: > > ii > space > to distinguish from "»" that 
a uied by iMtrtam. 


majKint, lisKntt> > 


m_ProtocolFormatV ectorMsp 


The key is a protocol value, and the list is the list of 
format values associated to the key. Because 
subscripting Q is not needed in this implementation, 
list is used for the vector implementation. This map is 
used to modify the map above if the protocol can take 
only one format. 


bool 


mJbFiistGetCalt 


This flag is used to caU the function in 
CProtoccLRcstrictionChcck. The ctxistructor set this to 
be true. The function, gctForniarAndProtocolVcctor, 
sets it to be false 


mafXiott IisKint> >::iterator 


ra_ForniatProtocolVcct(wMapIterator 


Iterator used to iterate the map. 


CFormatFrotocolCombmationChcck 


m_FormatrVotocolCombinationCheck 


This object is to check the combination of format and 
protocol 


CProtocolRcstrictionCheck 


mProtocoIRestrictionCheck 


This object is to check the protocol restriction. 
Currently, the only restriction is if protocol can have 
only one format support 



523 Function Definition* 



/////////////////////////////////////////////////////////////W 
/ /Function : CFormat?rotocol_lnf oxm&tionBase 

//Description: Constructor ~ 

//Preconditions : None 
//Postconditions: None 

//Algorithm: Set at bFirstGetCall to true 

niftummmiiitnmnmnmmtmumtmtuiminfm 



ttiitmtmmuifmimimmimmmmmtififtmmiiti 

/ / Funct ion : -CForaat Prot ocol_Inf o emit ionBase 

//Description: Destructor 
/ /Preconditions : None 
//Postconditions: None 
//Algorithm: Default 

/////////////////////////////////////////////////////////^^//^/ 



0 

73 ft 



http://www.str. nc»h .coiWdoc_c»trtroI/proj_docs/j 04/doc/q6_dj04_08/format _prot . yformitprotocoljn formationbased assJit 01/25/2000 



Page 73 of 79 



CFormatProtocoMnformationBase Class Specification 



Page 2 of 2 



///////////////////////////////////////////////////////////////// 



//Function: storeForaatAndProtocol 

//Description: Check the passed format and protocol values 

// to be valid or not. If valid, store the 

// values into the two maps 

//Preconditions: None 
//Postconditions ; None 

//Algorithm: 1. Send two values to check the combination 
// through is Format ProtocolCombinationOK 

// function. 

// 2. Check the return bool value. 

// 3. If yea, save format and protocol values 
// into two maps (Figure 5.4 of the 

// Specification, Q6-DJ04-08) 

// Else, do nothing. 



///////////////////////////////////////////////////////////////// 



///////////////////////////////////////////////////////////////// 



//Function: get Forma tAndProtocol Vector 

//Description: The function returns a format and a list 

// of protocol values associated with the 

// format through two parameters. The function 

// returns true if a format and list are 

// returned, false otherwise. 

//Preconditions : None 

//Postconditions: The format value is within the range. 

// The list is not empty and contains the values 

// within the range. 

//Algorithm: 1. If m_bFirstGetCall (Figure 5.5 of the 

// Specification Q6-DJ04-08) 

// 1.1 call the function to check the protocol 

// restriction. 

// "1.2 check if m_FormatProtocolVectorMap is 

// empty. If empty, set it to default 

// values of format and protocol by calling 

// s etDe fault Forma tAndP rot ocol function. 

// 1.3 set the iterator to begin C). 

// 1.4 set m_bFir3tGetCall to be false 

// 2. If iterator is end, return false. 

// else (Figure 5.6 of the Specification 

// Q6-DJ04-08) 

// get format and list to return and set 

// return parameters. 

// increment iterator. 

// Return true. 



////////////////////////////////////////////////////////////////// 



/////////////////////////////////////////////////////////////////// 



//Private Function: 
//Description: 
// 

//Preconditions : 
/ / Pos t condi t ions : 
// 

//Algorithm: 



s et Default Forma tAndProtocol 
The function sets the default values for 
format and protocol in the map. 
The m Forma tProtocolVectorHap is empty. 
The map contains one default format and a 
protocol list with one default protocol. 
Set the map with the default values 



/////////////////////////////////////////////////////////////////// 
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Author: Tctsuro Motoyama 

53 CFormatProtocolCombinationCheck Class Specification 
53.1 Function List 

public: 

CFonnalProtocolCombinationCheckO; 
-CFormatProtocolCombinationChcckO 

boo! isFormatProtocolCombinationOK(c<m5t tnt injiForrnat, const Lnt innPrctocol); 

private: 

void mitMatrixO; 

53 3. Class Attributes 



Type 


| Attribute Name 


Deicription 


map<irj(t» sct<int> > 


jm_CombinationMatrix 


Key is the format The set contains the protocols that arc valid 
for the particular format 



533 Function Definitions 



//////////////////////////////////////////////////////////////y// 



//Function: 
//Description: 
//Preconditions: 
//Postconditions : 
//Algorithm: 



CForraatProtocolCcrabinationCheck 

Constructor 

Nona 

None 

call initMatrix 



///////////////////////////////////////////////////////////////// 



///////////////////////////////////////////////////////////////// 



/ /Function: 
//Description: 
//Preconditions : 
//Postconditions: 
//Algorithm: 



-CFonnatProtocolCombinationCheck 

Destructor 

Nona 

None 

Default 



///////////////////////////////////////////////////////////////// 



///////////////////////////////////////////////////////////////// 



//Function: 

//Description: 

// 

// 

/ /Preconditions : 

//Postconditions : 

//Algorithm: 

// 

// 

// 

// 

// 

// 

// 



is Format P rot ocolCottbinationOK 

Check the passed format and protocol values 

to be valid or not. If valid, return yes, 

no otherwise 

None 

None 

1. 0s* find function of the Matrix for 
in_nFormat 

2. If returned iterator is end, return No 

3. get the set value for the key format 

4. Use the find function of the set for 
injiProtocol 

5. if~r« turned iterator is end/ return no 

6. return yes 




///////////////////////////////////////////////////////////////// 
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//////////////////////////////////////////////////////////////////// 
//Private Function: initMatnx 
//Description: 
// 
// 

//Precondition: 
//Poatconidition: 
//Algorithm: 
// 
// 
// 
// 
// 
// 
// 
// 



This function initializes m_CombinationMatrix . 

If new formats or protocols are added/ this 

function must be modified. 

None 

None 

1. Create the local set<int> 
2 for each format 

2.1 fill in th« local set 

with the protocol numbers 
that are valid for the format, 
using insert function 
m_CombinationMatrix [format] 

- local set 
clear local set 



2.2 



2.3 

iitniuinituiiunnmfiimmimmtmmnitnmmmnu 
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Author Tetsuro Motoyama 

5.4 CProtocol Restriction Check Class Specification 
5.4.1 Function List 



public: 

CProtocolRcstrictioitCheck<); 
-CProtocolRestrictionCheckO 

void getFormatProtocol Vccto rMap AftcrCh eckingProtoco [Restriction 

(map<int, list<int> > Jt inOut_Map, const map<mt; Hst<int> > & tn_MapJ; 

private: 

void initOneFormatRestrictkmQ; 
void oneFonnatRestriction 

(map<int, lisKinO > A inOut_Map, const mafKtnt, list<int > > & in_Map); 



5.4 J. Class Attributes 



Type 


1 Attribute Name 


Description 


vector<bool> 


|jm_bOncFonnatRc5triction 


Army size should be protocol size+1 . The position corresponds 
to the protocol. 



5.4J5 Function Definitions 

///////////////////////////////////////////////////////////////// 
/ / Func t i on : CProt o colRes t ri ctionChe ck 

//Description: Constructor 
//Preconditions : None 
//Postconditions: None 

//Algorithm: call init OneFonnatRestriction 

///////////////////////////////////////////////////////////////// 



///////////////////////////////////////////////////////////////// 



//Function: 
//Description: 
//Preconditions : 
//Postconditions : 
//Algorithm: 



-CProtocolRestrictionCheck 

Destructor 

None 

None 

Default 



///////////////////////////////////////////////////////////////// 



/////////////////////////////////////////////////////////////////// 



//Function 
/ / Dea c r ipt ion : 
// 
// 
// 
// 

//Preconditions : 
/ /Postconditions : 
//Algorithm: 



9«trormatProtocolVector«apAfterCheckingProtocDlRe»tricftion 
Check the restriction on the protocol. 
Currently, there is only one possible restriction 
defined in the requirements. If there are more 
restrictions, more private functions should be 
added and called. 
None 
None 

1. Call oneFonnatRestriction function 



Y 



/////////////////////////////////////////////////////////////////// 



//////////////////////////////////////////////////////////////////// 
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//Private Function: 

//Description: 

// 

// 

//Preconditions : 

/ /Postconditions : 

//Algorithm: 

// 

// 

If 

// 

If 

// 

If 



initOneFormatRestriction 

This function initialize the attribute 

m_bOne Forma tRes trict ion. If more protocols are 

added/ this initialization must be modified. 

None 

None 

1. use assign(size+l, false) to initialize the 
vector to false. 

2. set the entries of true. 

Note: for class debug version, use 
ifdef and 

bool s posl - m_bOneFormatRestriction[l] ; 
bool £ pos2 - m_bOneFormatRestriction{2] ; 
and so on to be able to see and to 



// change the value. 

/////////////////////////////////////////////////////////////^///// 



//////////////////////////////////////////////////////////////^//W 
//Private Function: oneFormatRestriction 

This function receives two maps and if the one 
restriction is true for given protocol, the 
content of inOut_Hap (m_FormatProtocolvectorMap) 
is adjusted accordingly? 
None 
None 

Iterate over the in__Map (m_ProtocolFormatVectorMap) 

1. get the key (pkey) 

2. If m_bQneFormatRestriction [pkey] 

2.1 get the value list of injiap for the key 

2.2 local int lastFormat - backO, 

2.3 iterate over the list 
if * iterator HE lastFormat 

iterate over inOut_Map[*iterator] list 
if the value EQ pkey 

erase the entry from the list 

3. Iterate over inOut__Map 
if value list is~"empty, 

erase the entry from inOut_Map 



//Description: 
// 
// 
// 

//Preconditions : 
/ /Postconditions: 
//Algorithm: 
// 
II 
if 
// 
// 
// 
// 
// 
// 
// 
II 
// 

// 

//Example: 

/ / mJbOneFo rmatRe s t r i ct ion 
// 
If 
if 
li 
li 
// 
// 
II 
// 
// 
// 
// 
// 
1/ 
// 
// 

// 4 i~ 1 

// inOut_Map[4] 
// erase value 2 

// 3 !- 1 
// inOutJ4ap[3} 
// eraa«*~value 2 

// 2 !-l 
// inOut_Map{2) 
// erase value 2 

// 1 — 1 
// 



0 12 3 4 

_ [0,0,1,0,1] (four protocols) 

0: false, 1: true 
inOut_Map (m. Format Pro toco lVectorMap) 

- ( 1, <C2,3,4> --> <1, 2, 3> 

2, <2,1,3,4> — > <1, 3> 

3, <3,4,1,2> — > <3, 4, 1> 

4, <2,4>> — > <> 
in_Map (m_ProtocolFormatVectorMap) 

- U, <1, 3, 2> 
2, 1> 
2> 

1, 3» 



2, 
4, 



<4, 
<4, 



3, 
3, 
2, 



pkey ~ 1 

pkey - 2 _ 
value list 
lastFormat 



m_bOneFormatRestriction[l] « 0 
iu_bOneFormatRestriction[2] - 1 
<4, 3, 2, 1> (2.1) 
1 (2.2) 



- <2,4> 
<4> 



1* 



* <3,4,1,2> 
<3,4,1> 

- <2,1,3,4> 
<1,3,4> 



pkey - 3 m bOneFormatRestrictiont3] - 0 
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// pJcey - 4 m_bOneFonnatRe3triction[4] » 1 



// value list - <4, 2, 1, 3> 

// lastFormat - 3 

// 4 != 3 

// inOut_Map[41 * <4> 

// erase value 4 <> 

// 2 !- 3 

// in0ut_Map[2] - <1,3,4> 

// erase value 4 <1,3> 

// 1 !* 3 

// inOut_Map[l] * <1,2,3,4> 

H eraaa value 4 <l,2 r 3> 

// 3 — 3 

// Iterate over lnOut_Map 

// if * inOut_Map_iterat or. empty 0 then erase 
// 

// inOut_Map 

// - I 1, <1, 2, 3> 

// 2, <1, 3> 

// 3, <3, 4, 1» 
// 



//////////////////////////////////////////////////////////////// 
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WE (I) the undersigned inventors), hereby declares) that 

My residence, post office address and citizenship are as stated below next to my name. 

We (1) believe that we arc (I am) the original, first and joint (sole) inventory) of the subject matter which is 
claimed and for which a patent is sought on the invention entitled 

Method and System of Remote Diagnostic, Control and Information Collection Using a Dynamic 
Linked Library of Multiple Formats and Multiple Protocols with Restriction on Protocol 

the specification of which 
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Q was filed on as 

Application Serial No, 

and amended on 

f""]was filed as PCT international application 

Number 
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and was amended under PCT Article 19 

on (if applicable). 

We (I) hereby state that we (I) have reviewed and understand the contents of the above-identified specification, 
including the claims, as amended by any amendment referred to above. 

We (I) acknowledge the duty to disclose information known to be material to the patentability of this 
application as defined in Section 1.56 of Title 37 Code of Federal Regulations. 

We (1) hereby claim foreign priority benefits under 35 U.S.C § 1 19(aMd) or § 365(b) of any foreign 
application(s) for patent or inventor's certificate, or § 365(a) of any PCT International application which designated at 
least one country other than the United States, listed below and have also identified below, by checking the box, any 
foreign application for patent or inventor's certificate, or PCT International application having a filing date before that 
of the application on which priority is claimed Prior Foreign Application^) 

Priority 

Application No. Country Day/Month/Year Claimed 
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We (I) hereby claim the benefit under Title 35, United States Code, $ 1 19(e) of any United States provisional 
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Application Serial No. 



Filing Date 
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No. 34,426; James J. Kulbaslri, Reg. No. 34,648; Richard A, Neifeld, Reg. No. 35,299; J. Derek Mason, Reg. No. 35,270; 
Surinder Sachar, Reg. No. 34,423; Jeffrey B. Mclntyre, Reg. No. 36,867; William T.Enos, Reg. No. 33, 128; Michael E. 
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to the firm of OBLON, SPIVAK, McCLELLAND, MAIER & NEUSTADT, P.C., whose Post Office Address is: Fourth 
Floor, 1755 Jefferson Davis Highway, Arlington, Virginia 22202. 

We (I) declare that all statements made herein of our (my) own knowledge are true and that all statements made 
on information and belief are believed to be true; and further mat these statements were made with the knowledge that 
willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 1 001 of Title 
1 8 of the United States Code and that such willful false statements may jeopardize the validity of the application or any 
patent issuing thereon. 



Tetsuro MOTOYAMA 



NAME OF FIRST SOLE INVENTOR 
Signature of Inventor 



Residence: 829 Stendhal Lane 
Cuptertino, CA 95014 

Citizen of: USA 



Post Office Address: Same As Above 



Date 



Avery FONG 



NAME OF SECOND JOINT INVENTOR 
Signature q/ Inventor / 



Residence: 25797 Annie Court 
Castro Valtov. CA 94552 

Citizen oft USA 



Post Office Address: Same As Above 



Date 



NAME OF THIRD JOINT INVENTOR 



Residence: 



Signature of Inventor 



Citizen oft 



Post Office Address: 



Date 

Residence: 



NAME OF FOURTH JOINT INVENTOR 



Citizen of: 



Signature of Inventor 

Post Office Address: 



Date 

Residence: 

NAME OF FIFTH JOINT INVENTOR 



Citizen of: 



Signature of Inventor 

Post Office Address: 



Date 



